Compatibility issues for datetime-related values:

• Valid data:

  • BigQuery's range starts from year 0001.
    • TIME range: 00:00:00 to 23:59:59.99999 (but the canonical format says "[.DDDDDD]: Up to six fractional digits")
  • MySQL's range starts from year 1000 (except for an error value starts from year 0000 which is already addressed);
    • TIME range: -838:59:59.000000 to 838:59:59.000000
      • Shall I raise an exception when timedelta.total_seconds() > 86399.99999(9)?
        This PR implicitly raises an OverflowError: date value out of range when timedelta.total_seconds() < 0.

• Supported output format:

  • https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-json#limitations

    When you load JSON or CSV data, values in TIMESTAMP columns must use a dash (-) separator for the date portion of the timestamp, and the date must be in the following format: YYYY-MM-DD (year-month-day). The hh:mm:ss (hour-minute-second) portion of the timestamp must use a colon (:) separator.

  • https://cloud.google.com/bigquery/docs/loading-data-cloud-storage-json#details_of_loading_json_data

    If you provide a schema, BigQuery also accepts Unix Epoch time for timestamp values. However, schema autodetection will not detect this case, and will treat the value as a numeric or string type instead.

When no schema provided, the current version of the operator assumes that MySQL's DATETIME and DATE values becoming BigQuery's TIMESTAMP, which doesn't accept Unix Epoch integer unless the downstream gcs_to_bigquery actually takes the output of _write_local_schema_file().

Should there be a schema, the current version of the operator sends integers and floats to BigQuery's DATETIME/TIMESTAMP and TIME, respectively. Issues are:

• For DATETIME, BigQuery will throw errors;
• For TIMESTAMP, although BigQuery accepts Unix Epoch integer in this case, calendar.timegm() will still cause troubles (unless the downstream gcs_to_bigquery uses a connection that switches to legacy SQL of BigQuery);

  >>> calendar.timegm((1000,1,1,0,0,0))
  -30610224000

• For TIME, BigQuery may silently convert to incorrect values.

As for DATE, if the schema is indeed sent to the downstream gcs_to_bigquery, then the current version will work. Otherwise, it will still encounter issues of BigQuery's integer-to-TIMESTAMP rejection and negative integers from timege() for edge cases.

A side note:
I suppose some usages might have been designed for BigQuery's legacy SQL dialect. However, since gcs_to_bigquery doesn't explicitly support it (only one line detects it for escaped_table_name), and standard SQL dialect is the default for Python library, it might be safe to follow standard SQL dialect's requirements.

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.